Waiting for #3876 to merge first before merging this

Alright @rbtr , I've made some changes, I just have 2 remaining questions:

• Why do you want the assign action specifically in the POST API?
  • I think it may be because POST alone (good rapper name?) with no action, implies you're creating a new resource (which isn't the case here)
• Why did you ask if a pod being created with the same name right after one was deleted would be a problem?
  • I've discovered that is a problem, but now want to know what you had in mind because we were talking about the podID
  • Were you thinking we need to pass more identification info such as InfraContainerID ?

Hi @rbtr , lmk what you think now with the latest changes, thanks

Alright @rbtr , I've made some changes, I just have 2 remaining questions:

• Why do you want the assign action specifically in the POST API?

  • I think it may be because POST alone (good rapper name?) with no action, implies you're creating a new resource (which isn't the case here)

Exactly, if you don't have an action in the URI, the implicit contract is that POSTing to /ibdevices/<id> is a create or update of the whole object.
Thinking about it from the other direction, if POSTing /ibdevices/<id> assigns a mac to a Pod...how would you create the ibdevice entity in the first place?

• Why did you ask if a pod being created with the same name right after one was deleted would be a problem?

  • I've discovered that is a problem, but now want to know what you had in mind because we were talking about the podID
  • Were you thinking we need to pass more identification info such as InfraContainerID ?

azure-container-networking/cns/NetworkContainerContract.go

Line 219 in 138e4f5

InfraContainerID() string

There's maybe a race here, since namespaced name is not unique. A pod could get a stale MTPNC?

Thinking about it from the other direction, if POSTing /ibdevices/ assigns a mac to a Pod...how would you create the ibdevice entity in the first place?

Yeah that's a good point, the ibdevices are provisioned at the Azure host level
So while CNS can't really create one, are you saying you'd like me to have the POSTing of /ibdevices/<id> "register" a device with CNS?

There's maybe a race here, since namespaced name is not unique. A pod could get a stale MTPNC?

Yes you're right, we could have a race condition met here

Lemme see what we do today (cuz this already happens)

Alright @rbtr , I ran some tests, and something that changes even when pods get the same names, is UID:

We could make this a required parameter for the POST API

• CNS could then add it to the MTPNC on creation
  • CNS will be creating the MTPNC in this scenario btw
• CNS could then check the MTPNC on each POST, and make sure the UID matches
  • If it matches, CNS knows the MTPNC is current
  • If it doesn't match, we know the MTPNC is stale, and CNS could return an error

Wdyt?

who creates the MTPNC? why don't we set an ownerref to the Pod so it gets GCed?

who creates the MTPNC?

Today, DNC-RC creates the MTPNC, however, in this new NUMA scenario, CNS will create the MTPNC instead

why don't we set an ownerref to the Pod so it gets GCed

For this new NUMA scenario, we could do that

Why haven't we done that in the past with DNC-RC making the MTPNC?

I don't know

Basically @rbtr , is there anything else you want different about this PR, besides adding an ownerref to the pod so it is GCed? (that anyways will come in a future PR when I actually implement the APIs, this PR is to establish the contract between the partner team and us)

Hey wait we may actually set an ownerref already (I probably just missed it), here is one example MTPNC that DNC-RC already creates today:

apiVersion: multitenancy.acn.azure.com/v1alpha1
kind: MultitenantPodNetworkConfig
metadata:
  creationTimestamp: "2025-05-29T17:51:35Z"
  finalizers:
  - finalizers.acn.azure.com/dnc-operations
  generation: 1
  name: ibpod1-deployment-5dbf8f965-sdgzr
  namespace: e2e-ns-d0s9t9ibfg06a1lnpsog
  ownerReferences:
  - apiVersion: v1
    blockOwnerDeletion: true
    controller: true
    kind: Pod
    name: ibpod1-deployment-5dbf8f965-sdgzr
    uid: 18a8b6b2-b247-4ae6-a351-5d56a203eab4
  resourceVersion: "14083"
  uid: 817a229e-24cd-4efc-b37c-75d4ff48cb5f

Looking more in the code to see where we do that

Yeah I found where it is added, I sent it to you privately

So, we know there's an owner ref on the MTPNC, of the Pod

Are you saying, we should also add, an ownerref on the pod, of the MTPNC?

This pull request is stale because it has been open for 2 weeks with no activity. Remove stale label or comment or this will be closed in 7 days

Hi @rbtr , Kshitija and I were talking and on the POST API, if the pod has 7 or 8 macs, the URL will get really long.. 😅
POST /ibdevices:assign?ibmacs=e6:ed:09:b1:97:7e,ea:2a:3f:19:fd:49,e9:b1:8b:f9:d1:e0,00:7b:34:84:c5:0f,5f:26:ba:f7:2b:41,07:81:05:db:2a:36,a8:e9:a1:50:3b:2a&podnamespace=mynamespace&podname=mypod

Can I move them into arequest body instead? 😅
POST /ibdevices:assign

{
"MACs": ["e6:ed:09:b1:97:7e",
"ea:2a:3f:19:fd:49",
"e9:b1:8b:f9:d1:e0",
"00:7b:34:84:c5:0f",
"5f:26:ba:f7:2b:41",
"07:81:05:db:2a:36",
"a8:e9:a1:50:3b:2a"],
"podnamespace": "mynamespace"
"podname": "mypod"
}

/azp run Azure Container Networking PR